OpenEdge Application Server:<br />Developing AppServer Applications State-free operating mode

Like stateless, an AppServer running in state-free operating mode does not dedicate any AppServer agent to a client connection. Also, like stateless operating mode, all AppServer agents remain generally available to execute remote procedure and user-defined function requests from all client applications. However, unlike stateless, an AppServer running in state-free mode is never physically connected to a single client (except for bound connections, as described in this section). Instead, clients are logically connected (bound) to the application service that the AppServer provides, and the AppServer broker serves, not as a physical connection point, but as a request listener.

When a client wants to send a remote procedure or user-defined function request for the specified application service, OpenEdge forwards the request to an AppServer that supports that application service. The AppServer broker, which is listening for requests from any client on the network, receives and dispatches the request for execution to any available AppServer agent in its agent pool. When the agent completes execution of the request, it returns the results to the broker, which passes them back to the client, and the agent becomes available to service another request that might be received and passed to it by the broker.

General AppServer-client interaction

The general interaction between a state-free AppServer and client proceeds as follows:

The client sends a request to a NameServer to return a to a specified application service.

The NameServer returns a list of AppServers to the client that support the application service.

Note: The algorithm the NameServer uses to choose the list of AppServers depends on whether the NameServer is configured for load balancing. For more information, see the "Load balancing and session models" section.

The client creates a certain number of physical connections for each AppServer in the list and maintains them in a , depending on pool connection parameter settings.

Note: Each in the pool is a separate TCP/IP connection to an AppServer broker in the list provided by the NameServer.

The client invokes an application service request (synchronously or asynchronously).

The client chooses an AppServer to handle the request based on the list returned by the NameServer and selects a physical connection that is available to send requests to the AppServer broker (a ). If there is no free connection to the AppServer broker, the client creates one (limited by the pool connection parameter settings).

The client sends the request to the AppServer broker over the (which is now unavailable for other client requests).

The connected AppServer broker passes the client request to an available AppServer agent. The broker continues to be available to handle other client requests.

The agent executes the request and returns the results to the broker, which forwards the results back to the client. The connection used by the client to the broker is freed and returned to the connection pool on the client. The AppServer agent is immediately available to handle a request from any client that sends one to the broker.

The client handles the results of the application service request and either invokes another request as in Step 4 or disconnects from the application service as in Step 10.

When the client no longer requires the application service, it disconnects from the application service and cleans up the connection pool and all resources associated with the logical connection.

The number of available simultaneous logical connections to a state-free application service is limited only by the performance required for each client that connects to the application service. The performance of each client connection depends on the availability of a free physical connection to an AppServer. The availability of free physical connections depends on:

The number and availability of AppServers on the application service list.

The resources of each AppServer machine.

The number of agents each AppServer is configured to startup and manage at one time.

The number and types of client requests to the state-free application service.

Connection management

By default, there are no physical connections between a state-free AppServer and a client—that is, all AppServer agents are available to handle requests from any client making a request for its application services. As long as a state-free AppServer has agents available (it has at least one agent that is not currently handling a client request), it can handle requests from any client on the network.

However, at any time during the handling of a client request, a client can become bound to the agent—that is, the AppServer agent handling the request becomes available to handle requests only from the client it is currently servicing. The function of this physical binding is very different from a bound connection in stateless operating mode (see the "Stateless operating mode" section).

A client can bind to an agent in state-free operating mode only by invoking a request to instantiate a persistent procedure. When this happens, the AppServer broker that receives the request creates a physical connection between the client and an available agent where the persistent procedure is then instantiated.

For the client, this physical binding is only valid for requests to execute internal procedures or user-defined functions of the remote persistent procedure that it has instantiated on this agent. If the client makes any other requests for the specified application service, all other available AppServer instances or other available agents of a single AppServer can execute these requests. For the agent, this physical binding means that it is no longer available to handle requests from any other clients while it is bound to this single client.

A bound agent becomes free (unbound) and is again available to handle requests from all clients when the bound client deletes the remote persistent procedure that it has created on the agent. Note that it is the successful instantiation of a remote persistent procedure that forces an agent to become bound to the client. If a client fails in its attempt to instantiate a remote persistent procedure, no binding between the client and AppServer agent occurs.

In general, then, a state-free AppServer agent is available to handle a client request as long as it is not currently processing a client request and as long as it is not waiting on an exclusive bound connection to a single client. If a state-free AppServer has no AppServer agents available to handle requests, it returns a run-time error to the OpenEdge interface (client or Web service) that sent the request.

To help a state-free AppServer session perform common tasks for each request that it receives, you can configure Activate and De-activate procedures on the AppServer. For more information on connection and request management on a state-free AppServer, see Chapter 2, " Programming the AppServer."

Performance considerations

A state-free AppServer provides the highest degree of availability and responsiveness to clients compared to a comparable configuration using any other operating mode. Because multiple state-free AppServer instances and their agents can handle multiple requests from one or more clients, multiple requests even from the same client can execute in parallel, vastly increasing the potential response time for a given request. This capability provides the highest degree of scalability compared to other operating modes. That is, a relatively small number of AppServer agents can support many more client requests than even for stateless operating mode. As long as clients never use bound agents, a state-free AppServer can make maximum use of its available agent resources to handle client requests. This operating mode thus maximizes throughput for large numbers of clients, especially if no attempt is made to maintain any context between client requests.

Context management

An AppServer running in state-free operating mode can provide context management in only two ways:

Using persistent storage managed by the application (“role your own”), such as a database that is keyed to specific clients or common information used by all clients.

When a client binds an agent to itself by instantiating a remote persistent procedure (see the "Connection management" section).

An agent does not reset any session context between client requests. However, there is no guarantee what client the agent will service next. So, allowing AppServer procedures when they are invoked to create persistent procedures or other objects that remain in the context of an agent after it services a client provides little benefit and is likely to create harmful memory leaks in the agent session.

For an AppServer running in state-free operating mode you can also configure Startup and Shutdown procedures that run in every AppServer session when it starts up and shuts down. You can use these procedures to establish and discard run-time context that the AppServer maintains in common across all client requests. For more information on the Startup and Shutdown procedures, see Chapter 2, " Programming the AppServer."